Serverside actions

ServerSide actions are used when you want to delegate work to the MDrivenServer.

Reasons for delegating to the MDrivenServer might be that you want a single performer (i.e. synchronous execution). This is the case when assigning numbers that must be unique. Other scenarios include calling remote systems to update data, or sending emails.

Activate serverside jobs for a ViewModel
2017-02-06 12h39 29.png

On the ViewModel Root class, choose the action "Edit criterias for server side execute". You will then see a different colour green edit area to edit serverside execution.

Serverside editing area.png
Serverside settings
Setting Explanation
Interval How often is this checked by the server
Serialized Blocking When true, the job should be small and quick - it is done within the main loop of server actions. If the job is long-running/slow it is better to leave it as FALSE so that the server responds to admin events faster (evolve, check checksum, etc)
Max Answers The PS Ocl expression will return this many at most - -1 is unlimited.
Pre EAL Action language that will be executed before PS-OCL. One example of usage is:
You do not need anthhing here but a good example is if you want to limit on a Time:
vYesterday:=DateTime.Today.AddDays(-1)  -- vYesterday must be a ViewModel variable

You can also use this to set something in your model that changes an Access Group that enables this viewmodel to be processed serverside.

PS OCL The expression the server will run every "Interval"-seconds, just after the Pre EAL has executed. The result from the expression should be a list of objects of the same class that your ViewModel root has.

For each item in the result, a ViewModel will be created and it's actions will be executed in order from top to bottom. Any changed data will be automatically saved to the database.

Example:
2017-02-06 12h58 38.png
Access group and restricting access

You can restrict access to a ViewModels using tagged values and access groups.

Use UIAllowed to disable access from an user UI by setting it to false.

But you can also use accessgroups to have more precise control over when access is allowed.

The problem is that if you set a access groups used by logged in users, the viewmodel used to execute serverside will not be available to the server itself. An executing serverside viewmodel does not have a logged in user.

The solution to this problem is to use the Pre EAL to set "soimething" that you then use in the OCL to enable an access group that has the right to use the serverside viewmodel.

For example like this;

Create access groups, in this example

  • DebugAccess (enabled when a administrator is logged in )
  • ServerSideAccess (enabled when the server is running)
Documentation Serverside actions 1714075936311.png

In this example SysSingleton has an added Boolean attribute, ServersideAccess

By having the same expression on both "Visible expression" and "View Enable Expression", the server side execution has access the viewmodel and run it's actions.

Then, in the viewmodel, set the Boolean attribute in SysSingleton to enable the access group when running.Documentation Serverside actions 1714076153948.png

This is the viewmodel Access Groups settings enabling access for the DebugAccess and ServerSideAccess groups.

Documentation Serverside actions 1714076367245.png

The effect of this setup being that admin or developer users can access the serverside viewmodels for testing using one access group, and the server accessing the viewmodel serverside using another access group. Users not logged in (not in any of these access groups, will be unable to access the viewmodel)


This page was edited 1 days ago on 04/25/2024. What links here